Release 10.1A: OpenEdge Development:
Progress Dynamics Basic Development

Client access to the database

It is entirely possible and “legal” to maintain a direct client/server connection to the application database while using the AppServer for some kinds of operations. Many applications have been built this way, some using the direct connection to read data in bulk, to populate browses for instance, while using the AppServer connection for updates, so that the execution of schema trigger procedures and other server-side logic does not require passing records to the client. In some cases, this can be effective. However, even without considering the future deployment options for your application, this technique can lead to serious performance limitations.

The Progress Dynamics model maintains the principle that there is never a database connection on the client. Observing this constraint will prepare your application so that you can deploy it using WebClient without any changes. WebClient lets you distribute and maintain your application worldwide without the need to deal with run time licensing issues and code maintenance for all your application’s users.

Observing this constraint also prepares your application for alternative client types, so that your application can be accessed through Progress WebSpeed®, or from a non-Progress client interface, or from future client platforms for which you might not yet be consciously programming.

But what restrictions are you facing when you give up your client database connection? Most obviously, your client-side code can no longer have explicit statements in it that access the application database. You cannot write FIND and FOR EACH statements against the database and you cannot construct and open database queries. Your access to the database must be through temp-tables passed between client and server. Progress Dynamics handles this for you in most cases, allowing SmartDataObjects and SmartBusinessObjects to be divided transparently between client and AppServer sessions, and passing data as needed in both directions.

But there are subtler requirements as well. Most significantly, perhaps, the Progress compiler will automatically compile any field validation you have defined in the database schema into any frame containing those fields. This includes, of course, Progress SmartDataViewers, which are just Progress frames with supporting code attached. If this validation requires database access, such as a CAN-FIND on a foreign key value, then the procedure will generate an error at run time if there is no database connection. There are other issues with this as well, which are discussed in Chapter 2, " Database Design Principles in Progress Dynamics." The recommendation is that you not use validation defined in your OpenEdge schema, or at least not rely on it executing in your Progress Dynamics user interface. The Progress Dynamics Object Generator, by default, removes validation from the SDOs it generates to help you avoid problems in this area.

The CAN-FIND validation is just an example of a client-side bit of business logic intended to provide immediate feedback to the user if a data value is not valid. Sometimes application developers, observing the guideline that there should be no direct client-side database connection, but still wanting to maintain the same level of user feedback, will insert calls to the AppServer on LEAVE of many fields in the application screens, to do a database lookup of some kind. This is not a good idea in most cases. As noted, a big part of the purpose of the AppServer is to minimize the number of calls between client and server. Adding lots of extra calls defeats the purpose and works against good performance. The Progress Dynamics lookup and combo objects satisfy the need for this feedback. In addition, they provide the user with a list of valid values from which to choose. The values are brought over from the server in a single call to maximize performance. You can define other kinds of validation that do not require a database lookup in the SDO for the table in a way that executes that logic on the client. These kinds of validations are discussed in the "Client-side data validation" section. By default, this logic executes when the data entry for the record is complete. If you want to add code to run the client-side field validation in the SDO on LEAVE of a field, you can do so without forcing a call across the AppServer connection.

So, in short, write your client application code so that it does not require any direct connection to a database. This goal will maximize your performance in a distributed environment and prepare you for successful deployment on the widest variety of client platforms. The Progress Dynamics objects are designed to support you in every way in achieving this goal.